…ng srcChan

When sshHandleChannel processes a session, two independent forwarders
run in parallel: agent-to-upstream requests (e.g. exec, env, pty-req)
go through sshForwardChannelRequests(srcReqs, dstChan), and
upstream-to-agent requests (e.g. exit-status) go the other way. The
agent-to-upstream loop is NOT awaited before sluice closes srcChan.

A fast upstream that, in response to exec, immediately replies + writes
data + sends exit-status + closes lets sluice's wait on the three
upstream-to-agent goroutines complete and close srcChan while the
agent-to-upstream forwarder is still mid-flight: it has received the
upstream's CHANNEL_REQUEST_SUCCESS reply via dstChan.SendRequest but
has not yet called req.Reply on the agent side. The agent then receives
SSH_MSG_CHANNEL_CLOSE before its session.SendRequest("exec", true, ...)
sees the SUCCESS message on ch.msg. gossh closes ch.msg on
SSH_MSG_CHANNEL_CLOSE, which causes the blocked SendRequest to return
io.EOF (channel.go:603-606). session.Output("cmd") surfaces this as
"exec command via SSH: EOF" even though the upstream replied
successfully.

The fix wraps each iteration of the agent-to-upstream forwarder in a
sync.WaitGroup. sshHandleChannel waits for the WaitGroup to drain after
the three upstream-side signals, then closes srcChan. Any in-flight
exec reply has been fully written to srcChan before the close arrives.

The race was deterministically reproducible on the e2e-linux push-event
runner since commit d27b05e moved srcChan.CloseWrite() out of the data
goroutine, narrowing the window between the upstream's reply landing
and sluice's close. Eight successive main-branch e2e runs passed
before d27b05e; the next two (after PR #38 and PR #40 merges) both
failed at TestCredential_SSHInjection with the EOF symptom.

Addresses Copilot review feedback on PR #41.

sync.WaitGroup.Add and .Wait race when Add is called concurrently with
Wait while the counter is zero — the Go runtime panics ("sync: WaitGroup
misuse: Add called concurrently with Wait"). The previous tracked
forwarder called Add(1) from inside a for-range loop that could enter a
new iteration at any moment, racing the main goroutine's barrier.Wait()
on a fresh counter.

Replaces the WaitGroup with an inflightBarrier struct (mutex + cond +
draining flag + counter). enter() returns false once draining is set so
the forwarder rejects any further request without bumping the counter,
which means drain() can converge even if a new agent request arrives
mid-drain. Replying false to a WantReply request unblocks any caller
blocked on ch.msg.

Adds TestSSHJumpHost_BurstCloseDoesNotDropExecReply, a 50-iteration
regression test that drives a no-sleep burst-close SSH server through
the jump host and asserts that session.Output never returns EOF. The
existing startTestSSHServer used by other ssh_test.go tests papers over
the race with a 50ms sleep before returning from the channel handler;
the new server omits that sleep so the race is deterministically
triggered without the inflightBarrier fix.

…ction per iter

Addresses Copilot review feedback on PR #41.

1. The burst-close test server's per-channel goroutine now defers
   ch.Close, so a request loop that exits without hitting the exec
   path (early agent close, non-exec-only request stream) still
   releases the server-side channel and its driving goroutine.

2. TestSSHJumpHost_BurstCloseDoesNotDropExecReply's loop now closes
   agentSSH and agentConn explicitly and waits on errCh with a 5s
   timeout per iteration. A leaked HandleConnection goroutine surfaces
   as a deterministic test failure rather than as silent resource
   exhaustion that could mask a regression in the close path.

Addresses Copilot review feedback on PR #41. The burst-close test
previously discarded the value from errCh, which would let a future
regression that produces a non-nil error from HandleConnection
teardown pass silently. The select now captures the return and fails
the iteration when non-nil, so any unexpected teardown error surfaces
explicitly.